The Secure Shell (SSH) protocol allows client computers to connect with servers to perform services such as remote login, file transfer, file copy and other secure network services over an insecure network such as the Internet. With an SSH connection, passwords are encrypted so that account and group authentication credentials are protected. FIG. 1A is a block diagram of a portion of the Open Systems Interconnection (OSI) model established by the International standards organization (ISO) depicting layers involved in a conventional SSH establishment process. The SSH protocol 10 is employed to establish a secure remote login between a client 30 and a server 70. The client 30 includes a computer platform 12 having a transmission control protocol/Internet protocol (“TCP/IP”) connection 14, or other comparable data stream connection. Correspondingly, the server 70 includes a computer platform 52 having a TCP/IP connection 54.
In general, the SSH protocol 10 securely connects client 30 and server 70 by establishing a session key between transport layers 16 and 56 of the client and server, respectively. The transport layer protocol provides server authentication, confidentiality, and integrity.
Once the session key is established, a user authentication protocol authenticates the client user authentication layer 18 to the server user authentication layer 58. An encrypted tunnel is then multiplexed between the client connection layer 20 and the server connection layer 60.
Two common user authentication methods are password authentication and public key authentication (i.e.; asymmetric authentication). Password authentication involves using a password to access resources on a target computer. An account identifier and password are typically sent from the client computer over an unsecured network, such as the Internet, to the target computer. The target computer, having access to the password for the account identifier, compares the password it received from the client computer to the known password for that account identifier. If the password matches, access to the target computer is granted. Otherwise, access is denied.
Password authentication requires that the password itself be sent over the unsecured network to the target server. There is potential for the password to be compromised by being intercepted by an unauthorized recipient while in transit. If this happens, the unauthorized recipient can use the password to gain access to any resources that the account has permission to access. For this reason, a secured connection is necessary to protect the password while in transit.
In addition to being intercepted while in transit, there are a number of other ways in which a password can be comprised. Storing the password in an unsecured location, such a non-password protected computer or writing it down on a piece of paper, may give an unauthorized user access to the password. A password-protected computer may also be venerable to unauthorized users, or hackers, who can gain access to a password. Passwords are also susceptible to brute force attacks, which involves using all possible passwords until the proper password is found.
Password authentication is not particularly suited for all authentication scenarios. Frequently, a non-user account on a client computer requires access to a target computer. Whereas a user account is typically associated with an individual, a non-user account is typically associated with a software application or system. A non-user account may be a script or software application that communicates with other software applications. For example, consider a software application that creates daily sales reports for an online store. The software application may run on a dedicated computer (i.e.; a client) and access the database (i.e.; a target) using its own non-user account in order to extract daily sales data. Authentication occurs each time the software application access the database. Since this occurs automatically and without human interaction, the password must be accessible to the software application. Having a password either accessible to the software application or coded into the software application itself increases the risk that the password will be compromised.
In addition, once a password is compromised, an unauthorized user can use the password until the password is changed. To minimize the risk of unauthorized access, passwords are typically only valid for a set time period. Therefore, maintaining security when using password authentication requires periodically changing passwords. This is not compatible with a non-user account in the above example because it would necessitate routinely modifying each no-user account every time the password is changed. If the account is not updated timely, the non-user account will be denied access, potentially leading to down time and interruptions in proper software operation.
Public key authentication is more sophisticated and secure than password authentication. Public key authentication uses a pair of keys, a public and a private key, that are generated by an algorithm. The keys are mathematically linked so they complement each other: one key can lock (i.e.; encrypt) data while the other can unlock (i.e.; decrypt) data encrypted by the other key. In one implementation of public key authentication, authentication occurs by encrypting a message (i.e.; data) with the private key, also known as “digitally signing” the message, and sending the message to the target computer. The target computer attempts to decrypt the encrypted message using the public key. If the decryption attempt is successful, and the decrypted message contains appropriate information, access is granted to the target computer. Otherwise, access is denied.
Unlike password authentication, public key authentication can be used over an unsecured communication channel. A new digitally signed message is created for each authentication attempt. If a digitally signed message is intercepted by an unauthorized recipient, it can not be used for subsequent access to the target computer. In addition, because public key authentication is difficult to compromise, it can be used indefinitely and unlike password authentication, does not require periodic password changes to maintain high security. This makes public key authentication particularity well suited for non-user accounts.
The SSH protocol is described by various Internet drafts from the Internet Engineering Task Force (IETF) including “SSH Protocol Architecture,” “SSH Transport Layer Protocol,” “SSH Authentication Protocol,” and “SSH Connection Protocol.” Relevant documentation includes Ylonen, T. and C. Lonvick, Ed., “The Secure Shell (SSH) Protocol Architecture”, RFC 4251, January 2006, and Ylonen, T. and C. Lonvick, Ed., “The Secure Shell (SSH) Transport Layer Protocol”, RFC 4253, January 2006, Ylonen, T. and C. Lonvick, Ed., “The Secure Shell (SSH) Authentication Protocol”, RFC 4252, January 2006, and Ylonen, T. and C. Lonvick, Ed., “The Secure Shell (SSH) Connection Protocol”, RFC 4254, January 2006, all of which are incorporated by reference herein. While the drafts of this documentation provide various standards for the SSH protocol, there is no definitive security policy established that sets forth procedures by which a server authorizes a request when the server is presented with the request by a client computer to establish an authenticated and protected tunnel over which to run an SSH service. This has resulted in substantial management obstacles for enterprises that require employees, consultants and/or vendors to access network resources using an SSH connection. Conventionally, implementers must maintain, at each server, authorization policies for individual clients and accounts, i.e., users and applications.
In addition, SSH providers include various vendors and/or open source entities. The multiplicity of providers generally results in implementation of diverse authorization protocols. Authorization is generally distinct from authentication. Before authorization is used to determine whether an identified user has permission to access a given resource, user authentication is first used to reliably establish the identity of the user. One known authorization protocol allows a user, once authenticated, to use all resources available through the SSH connection. This clearly presents security problems in enterprises where different accounts are provided for access to specified network information.
One common approach to existing SSH security policy management and enforcement is the implementation of configuration files at each server using the SSH daemon, i.e., a server-centric approach. One attempt to enhance security policies with respect to an individual server operating in an SSH protocol is described in U.S. Pat. No. 6,851,113 issued to Hemsath and assigned to IBM, which is incorporated by reference herein. In the Hemsath patent, an extension is provided on an SSH server whereby a set of user credentials are created, and the credentials are associated with a session key. While Hemsath states that a policy database of allowed users and permissions is preferably maintained in a centralized location for ease of administration, this is referring only to a centralized user registry on the particular server. However, the Hemsath patent is not in any way concerned with problems that arise when several target servers operating in the SSH protocol are to be administered.
Another common approach to existing SSH security policy management and enforcement focuses on the interaction between user and non-user accounts. When logging into a client computer, a user is typically authenticated using password authentication. Once successfully logged in to the client computer, the user has access to applications on the client computer. The applications may be configured to connect to a target computer using public key authentication, but using the keys for the application, not the user.
For example, one application may allow users to generate sales reports based on data pulled from a database. An application that is permitted to access the database will have an account with the database. When a user, who successfully logged in to the client, runs the application on the client, the application authenticates with the database on the target computer using public key authentication. The application is authenticated using the public/private key pair belonging to the application's account. The database, therefore, has no access to the identify of the user running the application. Instead, the database only has access to the identity of the application requesting the data. A user accessing a resource in this manner (i.e. accessing a resource as an authenticated identity other than the one belonging to the user) is known as “impersonation.” In the above example, the user is impersonating the identity of the application in order to access data in the database.
A number of problems exist when using impersonation to provide security and control access. First, the private keys must be stored in an unsecured manner. That is, the private key must be accessible to the impersonator. This creates an opportunity to bypass security and access controls. Each application must have access to a private key in order to authenticate with the target resource, whether the resource is a computer or an application. A user who successfully gains access, whether authorized or unauthorized, to a computer where the application resides will also have access to the application's public/private key pair. If the user obtains the private key, then the user can bypass the security and access protections built into the application and then use the application's account and identity to directly access any resource accessible by that account. Access to data in this manner constitutes a security breach because there is no way to restrict, audit or track access in that the target computer has no knowledge of the identity of the user, and any access control imposed by the application has been bypassed.
Second, impersonation limits the ability to control access on a user-basis. When a user accesses an application on a target computer using impersonation, the application has no indication of the user's identity and therefore cannot control access based on the user's identity. Using impersonation, access is generally only controlled on an application-basis, not a user basis. With no ability to track or control access, it sometimes becomes necessary to segregate data across multiple computers, which increases hardware and maintenance costs.
Third, impersonation is sometimes used by system administrators because it is convenient. Impersonation gives the user specific rights that might be necessary for configuration, troubleshooting, or debugging. The practice, however, reduces overall system security because any activity while impersonating cannot be traced back to the actual user.
FIG. 1B is a flow diagram of an account authorization process on a server-centric level according to the prior art. The process starts 202 after the SSH session key has been established between the transport layers of the client computer and the server. This protects account information transmitted over the connection, including account names and passwords. The first decision step 204 queries the server as to whether the account is authenticated according to the existing authentication protocol of the SSH standards. If the account is not authenticated, then the establishment of the requested SSH tunnel is rejected at step 218.
If the account is authenticated, the process then proceeds to a series of steps to authorize the user based on a server-centric user registry or configuration file. A processing step 206 is invoked, in which the source, i.e., client computer, is identified. The next decision step 208 determines whether the account is allowed. In conventional SSH authorization protocols, this step generally assumes that the account is allowed to access the target server from any source computer unless a particular source is specified. If the decision at step 208 is affirmative, i.e., the account does not specify a particular source computer, then the SSH session is established 216.
If the decision at step 208 is negative, then the next decision step 210 determines whether the account access is permitted from the particular source based upon consultation with the server-centric user registry. If the decision at step 210 is affirmative, then the SSH session is established 216.
If the decision at step 210 is negative, the process flow proceeds to a primary group identification step 212, in which the primary group membership for the user is obtained. The primary group membership is used to determine at decision step 214 whether the identified group is allowed based on group permission retained in the user registry stored in the target server. If the decision 214 is affirmative, then the SSH session is established at step 216 without restriction based on the source identity. If the decision at step 214 is negative, establishment of the SSH session is rejected at step 218.
While a server-centric policy management system generally following the authorization process described with respect to FIG. 1B can be acceptable for systems with one server operating the SSH protocol, it has been found that relying upon individual server administration policies in organizations operating a plurality of servers is rather cumbersome. Many enterprises operate several thousand, or more, servers, with resources accessed from many thousands of client computers. Configuration files containing specific policies must be specified or replicated at each server, requiring updates on a regular basis and/or when accounts are changed. This is difficult, if not impossible, to implement on a real time basis, and hence the likelihood of error is increased.
By using server-centric security administration policies, each server itself is a so-called “weak link” that can be compromised. If a particular server having the configuration files is compromised, an intruder could not only access data at that server, but could also modify the configuration file and/or the user registry thereby facilitating future intrusions.
Active Directory is a directory service component to Windows® server platforms, and provides the means to manage the identities and relationships within and among Windows® servers. However, many servers employ operating systems other than the Windows® operating system, such as UNIX or Linux operating systems.
It would, therefore, be desirable to have an access management system for managing access by individual users to a plurality of servers that is independent of the operating system being run in each server, and that avoids the practice of impersonation. Further, it would be desirable to store the policies in a variety of repositories; such Active Directory, LDAP directory, database, etc.